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Author's Note 


The approach offered here for security and/or risk assessment is presented from the perspective of the 
healthcare sector. In other words, the laws and regulations which govern the healthcare industry—HIPAA 
and HITECH-serve as security requirements for assessment and evaluation. It should be stressed, however, 
that the approach is designed as industry-neutral and can be applied to any business sector (e.g., finance, 
manufacturing, education, etc..). 
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Preface 


This book was born out of necessity. 


As an Information Security Specialist in the healthcare sector | needed a framework for evaluating Security 
and Risk in my IT environment that was also granular enough for me to determine compliancy with industry 
best-practices or standards. As my environment was becoming increasingly complex and diversified | realized 
a single-focus security/risk assessment was insufficient. | needed a method for both quantitatively and 
qualitatively assessing the security posture of my environment. 


But where to start? While aware of the requirements for information security imposed by federal law—the 
Health Insurance Portability and Accountability Act (HIPAA) and Health Information Technology for Economic 
and Clinical Health (HITECH)—I was unable to find a publicly available tool or published approach sufficient 
enough to evaluate compliance and simple enough to use without special software or training. 


While various security and/or risk assessment frameworks exist such as the International Organization for 
Standardization (ISO) and National Institute of Standards and Technology (NIST) Cybersecurity Framework 
(CSF) few include methodology for gauging compliance. Most formal security/risk assessments are commercial 
offerings, however, the Department of Health and Human Service, Security Risk Assessment (SRA) is freely 
available. 


As | have been using NIST security publications for some time | decided it may be a good place to start. The 
single drawback to using NIST as a standard, however, is that its guidance is chiefly directed at federal agencies 
and not the private sector. As NIST has taken on an expanded role in Cybersecurity research and publication, 
however, it has emphasized its publications as applying to non-government organizations (NGO) as well. | have 
also found that while commercially available SRAs may incorporate NIST standards they usually lack insight 
into which publications—or portion(s) thereof—are used in their products. This makes determining compliance 
challenging since a baseline for comparison is not possible. 


After researching the issue | came to the conclusion that | would have to develop a new approach for satisfying 
my security assessment needs. Fortunately, | was able to create this approach using NIST Special Publication 
(SP) series; specifically those for protecting “Controlled but Unclassified Information” or CUI. | was further able 
to use publications specific to data security for Operational Technology (i.e., Internet of Things or loT). In effect, 
through NIST publications | was able to develop security assessments for both Information and Operational 
Technology using a common quantitative and qualitative framework. 


Security/Risk Assessment is a fundamental task necessary for the protection of the Confidentiality, Integrity 
and Availability (CIA) of information. Unlike other NIST publications used for Cybersecurity, the security 
requirements used in this book—for Information Technology; note that Operational Technology requirements 
are directed towards federal agencies—are unique in that they specifically omit security requirements exclusive 
to the federal government. In other words, NIST’s guidance for protecting Controlled Unclassified Information 
(CUI) can be applied, in totality, to non-government organizations (NGO) without first having to be distilled 
of those security requirements exclusive to federal IT systems. Although its publications provide essential 
frameworks and methodology for security/risk assessment NIST guidance lacks the steps necessary for 
determining compliance. Generally speaking, NIST publications tell you what has to be protected and to what 
extent for a certain level of security (i.e., Low, Medium or High) but does not provide instructions on how-to 
accomplish this goal. This omission, however, is partly by design. NIST publication tend to be written with 
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flexibility and adaptability in mind. These attributes are important when applied to organizations of different 
sectors and sizes. 


This book enhances NIST publication guidance by augmenting the assessment process. Augmentation 
includes: 


Security Requirement ‘Satisfying’ statement 
Validation Point Tool 

Security Control Type (Healthcare only) 
Assessment Evaluation 

Statistical Analysis Summary 


These features serve to enhance Security/Risk Assessment by including not only core NIST elements for 
identifying weaknesses & vulnerabilities, and identifying risk but determining the level of compliance (via 
simple statistics) of an organization's IT environment. This knowledge can be used to satisfy regulatory or legal 
compliance, gauge organizational change, and assess compliance relative to established industry standards 
and recommendations. 


| hope you find it useful. 


Thomas P. Dover 
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Scope 


The process and procedures presented in this book are directed at the protection of information, indirectly or 
directly, that is designated by an organization to be Controlled but Unclassified Information (CUI). The word 
“Unclassified” is used within the context of federal government Information Systems. For the purpose of this 
discussion, however, ‘Unclassified’ information is any data deemed sensitive, company-confidential, or whose 
public disclosure would harm or interfere with normal business/organizational operations. 


For example, in healthcare, patient information (per HIPAA) is considered electronic Protected Health 
Information (ePHI) which requires protection from unauthorized access or disclosure. In this context patient 
information is considered CUI since the principles for information security and protection apply. 


While CUI does not directly apply to Operational Security (i.e., Internet of Things) the principles of information 
security and protection apply but are supplemented by additional security requirements involving data 
storage and transmission. It is further limited to Cybersecurity and privacy protection assessment & evaluation 
of loT devices used by or for the healthcare sector as it relates to HIPAA and HITECH requirements for 
protection of electronic Protected Health Information (ePHI). It should be noted, however, that the security 
requirements outlined for Medical loT devices (MIOT) are applicable to any loT device. 


This book does not address action(s) necessary for correction or mitigation (i.e., Reduce, Avoid, Accept, 
Transfer). 





ealth Insurance Portability and Accountability Act (HIPAA). 1996. 
ealth Information Technology for Economic and Clinical Health (HITECH). 2009. 
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Target Audience 


This book is intended for both student and practitioner. 


Students will find it useful for learning about the National Institute of Standards and Technology (NIST) 
approach to Information & Operational Security (IT/OT) and Cybersecurity and how to use NIST publications for 
practical security assessment. 


Practitioners tasked with conducting security assessments of Information or Operational Technology Systems 
will benefit from NIST best-practices and guidance which can be applied to real-world challenges as well as 
incorporated into an organization’s Risk Management Program. 


Finally, those responsible for the administration, management or oversight of Information systems which 
create, handle, store or transmit Controlled but Unclassified Information (CUI) or Internet of Things (loT) 
devices responsible for collecting and transmitting such information will find it helpful for determining how 
well their security practices comply with industry-standards or Best Practices. 
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Prerequisites 


Due to technical aspects of the material the recommended (but not required) background for completing a 


security/risk assessment includes working knowledge of: 


network technology 

desktop and mobile technology 

access control 

identity management 

the protection of controlled information 
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INTRODUCTION 


Whether simple or complex the goal of an effective security or risk assessment is to identify internal or external 
weaknesses and/or vulnerabilities associated with an information system (both traditional IT and loT), and 
determine the level of compliance with a given standard as well as evaluate the degree of risk such weakness 
or vulnerability poses to a system. 


A security assessment differs from a risk assessment in that it assesses compliance whereas risk assessment 
evaluates the impact and likelihood of a threat to a information system. 


Regardless of Sector or Industry, whether “traditional” IT or loT the first step towards protecting information is 
identifying the systems which store, transmit or manipulate it and assessing their level of security and/or risk. 
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The Shared Challenge of Security & Risk 
Assessment in Cybersecurity 


In some ways, conducting a security or risk assessment has shifted from a relatively straightforward task to a 
complex undertaking. Hosted and Cloud-based computing stand out as having contributed to this increased 
complexity due to their design and architecture. 


For example, it used to be that an application was (or could be) developed, hosted and maintained by a single 
company or organization. Since hardware and software resources would be under a company’s direct control, 
oversight and access to information needed for a security or risk assessment was readily available and easily 
mapped to security requirements. With the advent of distributed/Cloud computing, however, information 
about an application’s operation, performance and security are split among one or more organizations. The 
responsibility for security then becomes “shared” and identifying who is responsible for what (and when) may 
result in “gaps” in needed information. Moreover, since no two companies or organizations are alike (or operate 
alike) their approach to information and system security may be quite different. The challenge, therefore, in 
a distributed technology environment becomes how to best apply a common set of security standards or 
requirements uniformly in order to produce an accurate and balanced assessment. 


In healthcare the federal government addresses the issue of shared-responsibility in Part 1, Section 13401 of 
the HITECH Act. It applies HIPAA’s Administrative, Physical and Technical Safeguard provisions to any Business 
Associate (BA) who handles Electronic Protected Health Information (e@PHI). Moreover, it makes Business 
Associates responsible for the protection of sensitive information “in the same manner that such sections apply 
to the Covered Entity”. Since each company or organization (Covered Entity or Business Associate) are required 
to meet the same level of security, assessment is simplified since security requirements are applied equally 
regardless of business relationship. 


Similar regulations (PCI, SOX) apply to other industries such as Finance, Manufacturing and Energy. 


Regardless of industry or sector the responsibility to protect sensitive information (whatever its purpose) is born 
equally by any company or organization which has access to or otherwise “touches” (create, store, manipulate, 
transmit) sensitive or controlled data. 


In shared-security systems the requirements for Security/Risk Assessment do not change but the ability to 
(accurately) evaluate such system may. It becomes essential then that the processes and methods used 
for assessing security in this type of environment be based on established guidelines or recognized 
industry-standards. 


. Under HIPAA and HITECH, a Covered Entity (e.g., Hospital, Medical Practice) is the primary custodian of PHI and a Business 


Associate is an organization other than the Covered Entity (e.g., contractor, sub-contractor or 3rd-party service provider. 


2 | The Shared Challenge of Security & Risk Assessment in 
Cybersecurity 


Why Use NIST? 


Five reasons for using NIST publications: 


1. NIST publications represent recommended and Best Practices for federal government agencies to follow 
regarding Cybersecurity. Organizations partnering with the federal government are obligated to adopt 
these standards. Moreover, many non-government organizations (NGO) adopt and adapt NIST standards 
for their own Cybersecurity and Risk Management programs. 

2. NIST is often cited in federal laws, regulations, orders and statutes’ and Executive Order 140287 (Improving 
the Nation’s Cybersecurity), signed May 12, 2021, as a source for Cybersecurity guidance. It is also cited by 
federal Departments and agencies when promulgating rules and regulations governing specific critical 
sectors (e.g., Manufacturing, health, finance). 

3. NIST publications are used by private businesses and commercial vendors for the development of custom 
Cybersecurity and risk assessment programs. Some professional certifications in Cybersecurity are based 
on NIST standards. 

4. NIST publications serve as an authoritative source for cybersecurity “Best Practices”. 

5. NIST publications are often cited in regulatory or legal proceedings as the basis for a company or 
organization’s Cybersecurity strategy or Risk Management Program. 


1. Examples include lol Cybersecurity Improvement Act of 2020, passed in December, 2020; HIPAA Safe Harbor Act, an 
amendment to the Health Information Technology for Economic and Clinical Health Act (HITECH), signed into law in 
January, 2021; 

2. https:/www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity 

3. An example is the Department of Health and Human Services (HIPAA). See https:/www.hhs.gov/hipaa/for-professionals/ 
security/guidance/guidance-risk-analysis/index.html?language=es for an example of NIST citation. 


Why Use NIST? | 3 


Regulatory and Legal Issues 


Commonly held policies, procedures & practices for Cybersecurity can be traced to federal law or industry 
regulations. For example, the safety and security of medical information is linked to HIPAA! , financial 
transactions to SOX,and credit card transactions to PCI pss”. In each instance, compliance with specific 
requirements for information security and privacy are provided. 


Moreover, many insurance companies require companies to adopt safeguards and technologies specifically 
designed to protection data and systems. 


1. Health Insurance Portability and Accountability Act 
2. Sarbanes-Oxley Act 
3. Payment Card Industry - Data Security Standard 
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FISMA 


For NIST publications the Federal Information Security Management Act (FISMA) is a good way to 
demonstrate the link between laws and NIST publications. Originally passed by Congress in December, 2002" 
FISMA recognized the need for information security involving government information systems and directed 
federal agencies to develop programs for such protection. The law provided a framework for agencies to use 
that included the following areas: 


- Inventory of Information Systems 

- Categorize Information and Information Systems according to Risk Level 
- Security Controls 

- Risk Assessment 

- System Security Plan 

- Certification and Accreditation 

- Continuous Monitoring 


An important aspect of FISMA is its definition of information security: 
“.. protecting information and information systems for unauthorized access, use, disclosure, disruption, 


n 


es teehee eae? 
modification or destruction ... 


CIA 
FISMA provides three elements that define information security and privacy: 


CONFIDENTIALITY:“...preserving authorized restrictions on access and disclosure, including means for 


protecting personal privacy and proprietary information...” 


INTEGRITY“..guarding against the improper information modification or destruction, and includes ensuring 


information nonrepudiation and authenticity.” 
AVAILABILITY: “..ensuring timely and reliable access to and use of information.” 


Taken together the attributes of CIA comprise the basis of information security. 





FISMA* (2002) 





1. FISMA was updated in 2014 (Federal Information Security Modernization Act of 2014) but the essential elements of CIA for 
information security are retained in this update. 
2. FISMA (Public Law 107-347), Section 3542. Definitions (b)(1) 
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NIST (FIPS 199 & 200) 


FIPS 199 





FISMA* (2002) 
> FIPS 199 (2004) 











Two years later (2004), NIST published FIPS. PUB 199, Standards for Security Categorization of Federal 
Information and Information Systems. This short (13 page) publication defined the potential impact on 
information and information systems in the event of a security breach (which it defined as the loss of CIA). 


FIPS 199 categorized potential impact on “organizational operations, organizational assets or individuals” as 
Low, Moderate or High (Table 1). 


Table 1- Impact Level and Consequence 


CONSEQUENCE 
(to “organizational operations, organizational assets or individuals”) 


IMPACT 
Low Limited 
Moderate Serious 


High Severe or Catastrophic 


For security/risk assessment, ‘consequence’ is interpreted subjectively since consequence(s) can vary from one 
organization to another. For the purpose of discussion, however, a scenario involving a brick-and-mortar retail 
store might describe the consequence of an information system disruption as follows: 


Limited: one or more sales registers have failed but backups and redundant systems keep transactions flowing 
with little noticeable disruption to either store operations or customer service. 


Serious: one of more sales registers have failed and backup systems lag; unable to keep pace with transactions. 
Registers are shut down with noticeable disruption to store operations (i.e., long customer lines). 


Severe or Catastrophic: one of more systems have failed and backup systems are non-existent or have also 
critically failed. Registers are unable to process transactions and business is halted. There is an obvious impact 
on store operations. 


In each scenario, the ability to maintain norma! business operations is adversely impacted and it is within this 
operational standard that the level of consequence (Limited, Serious, or Severe or Catastrophic) is defined. 


FIPS 200 


. Federal Information Processing Standards (FIPS) 
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FISMA* (2002) 
> FIPS 199 (2004) 
> FIPS 200 (2006) 











In 2006, NIST published FIPS PUB 200, Minimum Security Requirements for Federal Information and 
Information Systems. It specified minimum security requirements for (federal) information and information 
systems covering seventeen security-related areas. As cited in FISMA, minimum security requirements are 
correlated to the level of adverse impact to Confidentiality, Integrity and Availability (CIA) caused by a data 
breach as outlined in FIPS 199. FIPS 200 also provided a methodology for determining an information system's 
security category (Low, Moderate or High). 


Below is an example of FIPS 200 minimum security requirement as it pertains to ACCESS CONTROL: 


Organizations must limit information system access to authorized users, processes acting on behalf of 
authorized users, or devices (including other information systems) and to the types of transactions and 
functions that authorized users are permitted to exercise. 


PUBLICATION LINKS 


While some NIST publications serve as standalone guides others utilize associated publications which 
supplement or complement their particular topic. For example, the NIST Cybersecurity Framework” and 
Control Catalog (SP. 800-53r5°) reference one another. Likewise, when discussing security\risk assessment there 
is a connection between FISMA, FIPS and NIST SP.800 171 r2/172°. 





FISMA* (2002) 
> FIPS 199 (2004) 
> FIPS 200 (2006) 
> SP.800-171r2/172 (2015) 
*Note: FISMA is a law passed by Congress and not a NIST publication 











2. This number has expanded and now consists of 20 areas (or Security Control Families) as outlined in NIST SP.800-53r5 
(Security Control Catalog). 

3. Framework for Improving Critical Infrastructure Cybersecurity 

4. Security and Privacy Controls for Information Systems and Organizations 

5. SP.800-171 was originally published in June, 2015 with updates to it or its companion publications (800-172 & 800-172A) in 
2016, 2019, 2020 and 2021 


NIST (FIPS 199 & 200) | 7 


a 


Security Assessment versus Risk 
Assessment (What's the Difference?) 


There are many sources available (both text and online) which can provide a detailed description of what Risk 
Assessment is and how to conduct one. While it is beyond the scope of this book to cover Risk Assessment 
understanding the difference between Security Assessment and Risk Assessment is important to information 
security. Therefore, a brief comparison of the two types is presented here. 


Though their objective is the same (i.e. protecting information) Security Assessments differ from Risk 
Assessments in what is evaluated and how. 


SECURITY ASSESSMENT 


. . : : ; oi 
A Security Assessment or Analysis evaluates requirements, relative to a security control or control family used to 
protect the Confidentiality, Integrity and Availability (CIA) of information. Once a solution for a security control 
is implemented the requirement is said to be satisfied. 


For example, a control requirement may be: 


Limit system access to authorized users, processes acting on behalf of authorized users, and devices 
(including other systems) 


Using role-based access, therefore, might be one type of control which satisfies the requirement. 


Security Assessments are often used to evaluate the overall security posture of an organization's information 
security program. Areas-of-concern can then be evaluated further for weakness with appropriate steps taken 
to correct or mitigate identified problems. As with Risk Assessments, Security Assessments can be quantitative 
or qualitative (or a combination of both) in order to determine the strength and correctness of applied security. 


RISK ASSESSMENT 


A Risk Assessment or Analysis identifies 1) threats to a system; 2) determines vulnerabilities (or weaknesses) a 
system possesses relative to the threat; and 3) evaluates the likelihood of the threat occurring and its impact on 
the system. Risk assessments are often, though not always, quantified in order to provide the degree or level” 
of risk. The basic formula for calculating risk is: 





L(ikelinood) of Threat” x Threat I(mpact) = R(isk) 





. NIST Control Catalog (SP.800-53r5) categorizes groups of security controls into Families. Examples of Control Families 


include Access Control and Configuration Management. 


. Degree or level of risk depends on the risk assessment model used. Some models use simple Low, Medium and High labels 


with numeric values of 1,2 and 3 whereas other models are more granulated (i.e., labels of Low, Low-Medium, Medium, 
Medium-High, High) with corresponding granulation for numeric values (1-5 or 1-10). There is no right solution and which 
numeric value(s) to use depends on the needs of the evaluator. 


. The term ‘Probability’ is sometimes used instead of Likelihood but for the purpose of Risk Assessment both have the same 
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Example: a small Datacenter [system] has no Uninterruptible Power Supply (UPS) [vulnerability or weakness] 
and is located in an area with a history of severe weather-induced power outages [threat]. 


Given this information the likelihood of the threat (severe weather) occurring is evaluated as Low, Medium or 
High. The impact of the threat on a known vulnerability/weakness is then evaluated (Low, Medium or High). 
Using the Lx | = R formula and substituting numeric values 1, 2 and 3 for Low, Medium and High labels a risk 
assessment might look like: 


Threat = Severe Weather Power outage 

2. Vulnerability\Weakness = No UPS 

3. Likelihood (it is likely, given history, that severe weather will occur) = 3 
Impact (a power outage would disrupt Datacenter operations (no power) = 3 
Likelihood x Impact (3 x 3) = 9 (out of a possible 9). 


Therefore, based on risk assessment the lack of UPS is a risk requiring mitigation. 


Summarizing, Security Assessments evaluate overall system security whereas Risk Assessment determines risk 
based on Threat, Vulnerability (i.e., weakness) and Impact. 


meaning. 
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SECURITY ASSESSMENT (IT) USING NIST 
SP.800-1'71R2 & SP.800-1'72 


In June, 2015 the National Institute of Standards and Technology (NIST) released Special Publication SP.800-171 
(Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations). This publication 
was succeeded by SP.800-171rl in December, 2016 and followed by SP.800-171r2 and its supplement SP.800-171B 
(Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, Enhanced Security 
Requirements for Critical Programs and High Value Assets) in June, 2019. The current version of SP.800-171r2 
was released in February, 2020. SP.800-171B was renamed SP-800-172 (Draft) and released in July, 2020. 


The purpose of SP.800-171r2 is to provide non-federal organizations with guidance for protecting the 
Confidentiality” of unclassified (but controlled) information. As stated in its Abstract 


This publication provides agencies with recommended security requirements for 
protecting the confidentiality of CU] when the information is resident in nonfederal systems 
and organizations; when the nonfederal organization is not collecting or maintaining 
information on behalf of a federal agency or using or operating a system on behalf of 
an agency; and where there are no specific safeguarding requirements for protecting the 
confidentiality of CUI prescribed by the authorizing law, regulation, or government-wide 
policy for the CUI category listed in the CUI Registry. The requirements apply to all 
components of nonfederal systems and organizations that process, store, or transmit CUI, 
or that provide security protection for such components. 


Though not specifically intended for Healthcare Delivery Organizations (HDO), security requirements contained 
in SP.800-171r2 are nevertheless applicable to the healthcare sector. This is due, in part, to the Department 
of Health and Human Services (HHS) and Office of Civil Rights (OCR) references to NIST publications’ in 
published documents and online guidance regarding cybersecurity protections and HIPAA’s Security Rule. 
For example, HHS-OCR, Security Risk Assessment (SRA) Tool” references NIST publications in its User Guide. 
Moreover, vendors who develop security tools (e.g., IDS, antivirus, email protection) and Managed Security 
Service Providers (MSSP) often refer to NIST guidelines as “industry-standards”. 


In April, 2021, NIST released (Draft) SP.800-172A (Assessing Enhanced Security Requirements for Controlled 
Unclassified Information). Per NIST, “This generalized assessment procedures described in this publication 
provide a framework and starting point for developing specific procedures to assess the enhanced security 
requirements in NIST Special Publication 800-172°." 


1. Primarily federal contractors, or companies, agencies or organizations doing business with the federal government. 

2. Confidentiality is one part of the control triad for protecting sensitive information such as Electronic Health Record(s). The 
other parts of the triad are Integrity and Availability. Together, they form the CIA of cybersecurity. 

3. “..processing...healthcare data;” SP.800-171r2, p.1 

4. For example, the NIST Cybersecurity Framework and SP.800-53r5 (Control catalog) are often referenced in HHS regulations 

concerning protection of patient information. 

5. Available at The Office of the National Coordinator for Health Information Technology, Office of Civil Rights, Department of 

Health and Human Services (https:/Awww.healthit.gov/topic/privacy-security-and-hipaa/security-risk-assessment-tool) 

6. See ‘Cautionary Note’, p. vi 
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In effect, SP.B00-172A uses determination statements and Organization-defined parameters as procedures 
for meeting assessment objectives. Meeting a determination statement results in a finding of Satisfied or 
Other than Satisfied. It then introduces three specific assessment methods (Examine, Interview, Test’) for 
defining the “nature and extent of the assessor’s actions.” Also introduced are associated attributes Depth and 
Coverage. 





Examine is “the process of checking, inspecting, reviewing...to facilitate understanding, achieve 
clarification or obtain evidence.” 


Interview is “the process of conducting discussions with individuals or groups...to facilitate 
understanding, achieve clarification or lead to the location of evidence.” 


Test is “the process of exercising one or more assessment objects under specific conditions to 
compare actual with expected behavior.” 











Each assessment method may contain one or more Object Specifications, Mechanisms, and Activities. These 
objects serve as evidence or proof through which assessment method requirements were met. 


The attributes Depth and Coverage are used to describe the depth (i.e., rigor) and breadth (i.e., scope) of the 
assessment method review. For each method one of three values (Basic, Focused and Comprehensive) is used 
to describe the level of analysis. 





Basic employs “high-level reviews, checks, observations or inspections of the assessment object.” 
Focused employs the above plus “more in-depth studies and analysis.” 


Comprehensive employs the above plus “detailed, and thorough studies and analyses of the 
assessment object.” 











As can be seen, each value represents a greater depth and breadth of analysis & review for a particular 
assessment method. 


7S. , 8 : 
It should be noted that in its ‘Cautionary Note’ statement NIST notes that the assessment methods and objects 
“do not necessarily reflect, and should not be directly associated with, compliance or noncompliance with the 
requirements.” 


An example of how to employ the assessment methods and their attributes of SP.800-172A are provided in 
Appendix A. 


7. SP.800-172A, Appendix C provides extensive description and explanation of all assessment methods and attributes. 
8. Ch3, p.7 
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Process 


The process for completing either SP.800-171r2 (medium-level security requirement) or SP.800-172/172A 
(enhanced/high-level security requirement) assessment consists of satisfying each control requirement then 
determining compliance for both individual and aggregate control families. 


It should be stressed that SP.800-171r2 defines its control baseline security level as being for moderate-impact 
information systems and such level would cover healthcare-service providers handling, transmitting or storing 
electronic Protected Health Information (ePHI). SP.800-172 requirements are enhancements to SP.800-171r2 
and therefore offer stronger security which would be needed for high-impact information systems. SP.800-172 
contains thirty-four (34) enhanced security-control requirements and SP.800-172A offers assessment methods 
for evaluating assurance with SP.800-172 requirements. 


An advantage of using both SP.800-171r2 and SP.800-172/172A is that security assessments can be performed 
from the perspective of both medium and enhanced-level security. Evaluating this way allows an organization 
to determine the level of compliance for each security level and to what extent it is being implemented. 


In addition to control-requirement baseline, SP.800-172 has incorporated a new metric called Adversary Effects. 
Per NIST: 


..adversary effects...describe the potential effects of implementing the enhanced security requirements 
on risk, specifically by reducing the likelihood of threat events, the ability of threat events to cause harm, 
and the extent of that harm. Five high-level, desired effects on the adversary can be identified: redirect, 
preclude, impede, limit, and expose.” 


For Adversary Effects, a simple (aggregate) matrix has been created to view the overall impact of 
security-control implementation. 


An example of how to apply Adversary Effects is provided in Appendix B. 
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Methodology 


Special Publication 800-171r2 utilizes FIPS-200' and SP.800-53r5° as the basis for its recommended Security 
Requirements. FIPS-200 defines the minimal security requirements for Low, Medium and High-impact 
information systems as outlined in FIPS-199°. NIST SP.800-53r5° identifies twenty (20) ‘control families” and 
SP.800-171r2 utilizes a subset of these families. Control Families are groupings of security controls which 
address a specific security requirement. For example, Access Control deals with the methods, processes and/or 
procedures by which a user is granted access to a network or system. 


SP.800-171r2 (and by association SP.800-172/172A) omits” seven control families contained in SP.800-53r5 that 
are specific to the federal government. It uses the remaining 13 ‘control families’ but also incorporates a single, 
unique control family (Security Assessment). Together, these 14 control families form the basis for its one 
hundred ten (110) security-control requirements. 


Table 2 displays SP.800-53r5 control families’. Those highlighted in gray/bold have been omitted from 
SP.800-171r2 security baseline requirements due to their unique ‘federal’ nature. Tailoring requirements in this 
manner makes application easier and results more accurate when applied to non-government sectors such as 
healthcare. 


. NIST Federal Information Processing Standards (FIPS) 200, Minimum Security Requirements for Federal Information and 


nformation Systems. Released March, 2006 


. NIST SP.800-53r5, Security and Privacy Controls for Information Systems and Organizations. Released August 2017. Final draft 


published March, 2020 


. NIST Federal Information Processing Standards (FIPS) 199, Standards for Security Categorization of Federal Information and 


nformation Systems, NIST. Released February, 2004 

NIST SP.800-53r5, Security and Privacy Controls for Information Systems and Organizations. Released August, 2017. Final 
draft released March, 2020 

Control Families are security controls (applied to technology systems) which are operational, technical and management 
(i.e., administrative) safeguards used to protect the confidentiality, integrity and availability (CIA) of information systems 











. “..some of the security requirements expressed in the NIST standards and guidelines are uniquely federal, the requirements 


in this publication have been tailored for nonfederal agencies.” SP.800-171r2, p.3 


. Note: Security Assessment is not an SP.800-53r5 control family. It is listed here for reference but is cited only in SP.800-171r2 


and SP.800-172 
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Access Control 


Physical and Environmental Protection® 





Assessment, Authorization and Monitoring 


PII Processing and Transparency 





Audit and Accountability 


Planning 





Awareness and Training 


Program Management 





Configuration Management 


Risk Assessment 





Contingency Planning 


System and Services Acquisition 





Identification and Authentication 


*Security Assessment? 





Incident Response 


System and Communications Protection 





Maintenance 


System and Information Integrity 





Media protection 


Supply Chain Risk Management 





Personnel Security 





Table 2 


8. SP.800-171r2 cites this family as ‘Physical Protection’ 





9. This control family is not included in SP.800-53r5 but is unique to SP.800-172. Reference only. 
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Design 


General Framework 


é . 1 a ; 

Microsoft Excel was used to create the Security Assessment Workbook. Control-families are placed in separate 
F F . 2 

worksheets along with summaries for Assessment Snapshot, Compliance, and Adversary Effects_. 


Data entry is accomplished through individual Control Family worksheets (example: Awareness and Training 
below). Questions are drawn verbatim and directly from their NIST publications. Although only two pieces of 
information are necessary to satisfy the question (i.e., requirement); Satisfaction of Requirement and Satisfying 
Statement, other information (Name, Validation Point/Tool, Security Control Type) ensures a complete and 
comprehensive answer. 


# Com 







— vation sxutyensaa +=: SQEVELFAl INformational Reference worksheets are 
-oinUTo« (Type) 
included in the Security Assessment workbook but 





pertain to healthcare (HIPAA) requirements 


reporting potential indicators of inser threat, 3rd Party ‘Admin 


rma! —t governing Administrative, Technical and Physical 
comin: a: controls. 


(Njo 0 
(PL) PartiaLLOw Partly do it but ata low (0%-25%) compliance level 0.00.25 
(PM) Partia- MODERATE Partly do it but at a moderate (25%-50%) compliance level 0.25-0.50 
(PH) Partial HIGH Parlly do it but ata high (50%-75%) compliance level 0.50-0.75 
(D)oes not Apply 0 


(Brena was Formulas, calculated cells and cell references are 


Note: (P) values can be range between 0.25-0.75. See STATS tab for details. 


used extensively to simplify data entry and avoid 


Figure 1. Assessment (tab) screen highlighting variable cells. | input or calculation error. 











In addition to control requirements all worksheets contain the following variables: 


— Satisfaction of Requirement (Y/N/P/A/D) with corresponding value (0-1) 
— Satisfying Statement 

(maps to SP.800-172A Examine assessment method) 

—Name 

(maps to SP.800-172A Interview assessment method) 

— Validation Point/Tool (text) 

(maps to SP.800-172A Test assessment method) 

— Security Control-HIPAA Type (Administrative, Technical, Physical) 
{Healthcare sector only} 


Note: SP.800-172 (only) Enhanced Security Requirements contain the following column/row variables: 


Assessment Methodology (Examine, Interview, Test) 
Depth & Coverage (Basic, Focused, Comprehensive) 


See Appendix A for details. 


1. The Workbook is included as part of this book and can be downloaded from the Downloads Page. 
2. Snapshot, Compliance and Adversary Map worksheets display aggregate data pulled from control-family worksheets. 
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1. 


Variables 


Variable: COMPLIANCE & VALUE (Figure 1) 

Type: String or Text 

Definition: Value expressing organizational compliance with and satisfaction of the security requirement. 
Numeric value is assigned to text value (e.g., Yes = 1) which is then used to calculate individual, group and 
statistical compliance. 


The organization: 

(Y) performs this task’ 

(P) partially performs this task 

(A) uses an alternate approach to perform this task (that satisfies the requirement) 
(N) does not perform this task 

(D) this control requirement does not apply 


Variable: VALUE 

Depending on compliance, the following numerical values are automatically assigned: 
YorA=1 

P(L)(M)(H) = Low (.25), Medium (.50), High (.75) respectively 

DorN=0 


¥ Compliance | Value ACCESS CONTROL (AG) (si aie) Validation Security Control 


Point/Toot (Type) 
‘acting on behalf of authorized users, and devices (inching ther systems). “Ret Dir (AD) Tool2 Farin 
Tool 3 








Figure 1. Compliance (note: Value (0-1) is automatically Variable: SATISFYING STATEMENT (Figure 2) 
entered depending on level-of-compliance) ; 
Type: String or Text 


Definition: a short but concise statement conveying how the (control) requirement is satisfied. 


Normally, security assessments require detailed explanations of policies and/or procedures in order to satisfy 
a particular security requirement. Such detail may require additional allocation of resources (i.e., time, staff & 
effort) to complete. The approach taken here is to provide a “trimmed” answer which nevertheless satisfies 
the requirement. For example, under ACCESS CONTROL, the question: (do you) “Limit system access to 
authorized users, processes acting on behalf of authorized users, and devices (including other systems)? A 
short, satisfying statement would be (yes) via “Role-based Access Control (RBAC)”. The trimmed statement, 
Role-based Access Control (RBAC), is placed in the cell directly below the control-requirement. 


# Compliance Value ACCESS CONTROL (AC) (a 








Validation Security Control 
Point Too! 
FatDr (AB) Tool? 


faa = Variable: NAME (Figure 3) 
Type: String or Text 





Figure 2. Satisfying Statement 


Definition: The person responsible for providing 
the Satisfying Statement. This value is normally placed in the cell directly below the Satisfaction of 
Requirement (Y, N) variable. 


7 Gomplanes | Vaue ACOEES CONTROL HC) cx 
fare 


Figure 3. Name 








Validation Security Control 
PointToo! 
2 


Soemoeenmennnnnns Sa =" Variable: VALIDATION POINT/TOOL (Figure 4) 
Type: String or Text 








The term ‘task’ implies steps taken to satisfy the control requirement. 


7 Os 


3. 


[4] 
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Definition: a short, concise statement describing the tool, process or procedure used to satisfy the control 
requirement. 


This information describes what application, utility, or process is used to satisfy the control requirement. Often, 

the same tool is used to satisfy multiple requirements or multiple requirements are satisfied by a single tool. 
. 4 . 

(an example is an IDS_ for network security). 


¥ Compliance Value ACCESS CONTROL (AC) (at 








Validation Security Control 
Point Too! 


: =="7— =" Variable: SECURITY CONTROL/TYPE* (Figure 5) 
tion Point/Tool This value directly references HIPAA’s Security Rule 


which requires security controls to be categorized as 














ote-pasea! 3 


Figure 4. Valida 





Administrative, Technical or Physical. Most often, a security control has but a single categorization but there 
are instances where a control may encompass more than one. For example, establishing an operational 
incident-handling capability may be categorized as both an Administrative and Technical control. 

















Ay TT ten aia 
= oor i i en = * this variable is only required for healthcare 
Figure 5. Security Control Type (note: applies to healthcare assessments. 


(HIPAA) sector only) 


4. Intrusion Detection System (IDS). 
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Using the Assessment Workbook 


In effect, the Security Assessment consists of two segments; worksheets containing questions (requirements) 
related to SP.800-171r2/172 Control Families (Figure 1) and worksheets containing Snapshot summary and 
Compliance evaluation (Figure 2). In addition there are several worksheets that contain useful reference 
information for completing the Assessment. 


The Control Family worksheets are used for input and are the only worksheets requiring data. The Requirement 
(Satisfied?) field is the only required field whereas all others-Satisfaction Statement, Name, Validation Point/ 
Tool, HIPAA Security Control (Type) and Assessment Method (for Depth and Coverage)-are optional (Figure 2). 


Information entered into each worksheet is then used as input for Snapshot and Compliance worksheets (note: 
Adversary Map data is manually entered and not considered essential for completion of the Assessment. See 
Appendix B for further information). 


# Requirement Value 
iad? 
py 








A closer view the Control-Family worksheet (Figure 1) 
shows incorporation of SP.800-172A assessment 
methods (Figure 3). Methods are used only to 





evaluate enhanced/High security requirements. 


SP.800-172A 











Assessment 

Examine Basic Basic 
entry worksheet Interview Basic Basic 

Test Basic Basic 





Examine Comprehensive Comprehensive 
Interview Comprehensive Comprehensive 
Test Comprehensive Comprehensive 

















saan Examine Comprehensive Comprehensive 
Figure 2. Control-Family Snapshot Interview Comprehensive Comprehensive 
Test Comprehensive Comprehensive 






ne, ronson ors be orpanczon 








Note: Depth & Coverage values do not impact 
satisfaction value. See ‘How to use this 
Workbook’ tab for further details. 


Figure 3. Assessment Method matrix 


In the context of a security assessment, completion is the extent to which all questions have been answered 
(i.e., satisfied). Given the number of questions in the assessment the more complete it is the more accurate the 
results. 


Compliance is defined as the extent an organization’s security ‘posture’ Is aligned with and satisfies individual 
requirements of SP.800-171r2 (Medium-security) or SP.800-171r2 and SP.800-172 (Enhanced/High-security). 


. SP.800-171r2 contains 110 control requirements and SP.800-172 has 34. Both publications comprise a total of 144 
security-control requirements. 
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Compliance establishes whether or not, for a given security-control the Validation Tool maps to the 


requirement. This process is especially useful in identifying security requirements with either no associated tool 


or an insufficient one. 


Point value and compliance percentage is computed for each control-requirement worksheet with results 


displayed at the bottom of each sheet (see Figure 1). As stated earlier, this information is used as reference 


for the Snapshot worksheet and as input for the Compliance worksheet. The Snapshot worksheet provides an 


aggregate view of all Control-Family responses as well as a summary of completion and compliance (Figure 2). 


Compliance is summarized via the Compliance Summary worksheet (Figure 4). All values are pulled from the 


individual Control Family worksheets. Optional color-coding is used to aid readability. 





MED IUM-Lovl Sacurty Requirement 
NSTSP-800-171F2 Compliance Suranary 











































































































Figure 4. Individual and aggregate Control-Family 
compliance summary 





A data table and radar (aka spider) chart provide 
tabular and graphical depiction of each Control 
Family’s value for aggregate compliance. The radar 
chart is especially useful for viewing deficiencies and 
areas which need to be addressed. 


An acceptable individual control-family or aggregate 
compliance level is left to the discretion of the 
organization as there is no published or uniformly 
agreed upon standard. 


Regardless of threshold, compliance provides an organization with an idea of how well its security posture 


compares to established or recommended industry-standards. 


2. A radar chart compares the values of three or more variables relative to a central point. It’s useful when you cannot directly 
compare the variables and is especially great for visualizing performance analysis or survey data. 
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SECTION III 


SECURITY ASSESSMENT (OT) USING NISTIR 
8228 


Author’s Note: 


On 11/29/21, NIST published Special Publication (SP) 800-213, loT Device Cybersecurity for the Federal 
Government. This publication builds upon and expands considerations for Internet of Things (loT) security 
initially published in NISTIR publications 8228, Considerations for Managing Internet of Things (loT) 
Cybersecurity and Privacy Risks and 8259A, loT Device Cybersecurity Capability Core Baseline. 


As stated in SP.800-213 Abstract: 


This publication contains background and recommendation to help organizations consider how an 

lol device they plan to acquire can integrate into a system. loT devices and their support for security 
s eet J: : 2 

controls are presented in the context of organizational and system risk management. 


New and updated security requirements contained in SP.800-213 will be incorporated into a future edition of 
this book. 


Finally, and as has been stated throughout this book, specific guidance for conducting and completing a 
security assessment has been directed towards the healthcare sector but the principles and process described 
within can be equally applied to any sector or industry. 


1. NISTIR 8228 & 8259A (8259 series) published in June, 2019. 
2. NIST-SP. 800-213. [ii] 
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Introduction 


According to Cisco Internet Business Solutions Group the ‘Internet of Things’ (loT) began sometime between 
2008 and 2009 when the number of “things or objects” connected to the internet exceeded the number of 
people connected. 


Published references to the Medical Internet of Things (MIoT) most likely started between 2012 and 2013. In 
2012, the Government Accounting Office (GAO) recommended in the August edition of its Highlights report 
to Congress. that the FDA should “develop and implement a plan expanding its focus on information security 
risks.” Indeed, in 20137 the Food and Drug Administration (FDA) issued medical device manufacturers guidance 
for the cybersecurity of medical loT devices” which represented the agency's “current thinking on this topic.” 


The Healthcare sector has been quick to incorporate MIoT into clinical operations as such use offers greater 
efficiency, improved operations, cost savings and most importantly, improved patient outcomes. Examples 
where MIoT are employed include blood pressure and glucose level monitoring, pulse oxymeters, weight/BMI 
scales, thermometers, spirometers, and EKG monitoring. 


The key to success of MIoT (in fact, all loT) is internet-connectivity and the ability of MloT devices to transmit 
(patient) information. 


In December 2020, President Trump signed into law the /oT Cybersecurity Improvement Act of 2020. This 
law, in part, directs the National Institute of Standards and Technology (NIST) to take steps for the increased 
cybersecurity of lol. In accordance with this law, in late November NIST published Special Publication (SP) 
800-213 (loT Device Cybersecurity Guidance for the Federal Government: Establishing loT Device Cybersecurity 
Requirements). Although written for government agencies the guidance contained in NIST Special 
Publications can be used by non-government organizations as well and SP.800-213 is no exception. 


Based on NIST guidance, a qualitative framework for assessing IoT (and by extension MIoT) cybersecurity and 
privacy protection is possible. Using Expectations for MloT cybersecurity and privacy protection outlined in 
NIST.IR 8228 (and associated publications’) a set of criteria is used to assess security and compliance, and in 
turn, evaluate weakness or (data) exposure which a MIoT device may pose to a healthcare organization’s IT 
environment. Moreover, such evaluation is crucial for complying with HIPAA/HITECH regulations governing the 
Confidentiality, Integrity and Availability (CIA) of Protected Health Information (PHI). 


How can healthcare organizations (from small Practices to large HDOs ) evaluate adherence to the 
cybersecurity and privacy protection of MloT devices used in clinical settings? This discussion suggests an 
approach for such evaluation which make it possible to quantitatively assess cybersecurity and privacy 
protection, and determine relative compliance with recommended standards. It further allows organizations to 


1. GAO Highlights, GAO-12-816. 

2. Content of Premarket Submissions for Management of Cybersecurity in Medical Devices. Guidance for Industry and Food 
and Drug Administration Staff. First draft published June 14, 2013. Food and Drug Administration, et al. 

3. It should be noted that the FDA issued guidance for “...Software Contained in Medical Devices” in May, 2005, however, this 
publication pre-dated iOT and concerned itself with embedded software. 

4. NIST Cybersecurity Framework (CSF), NISTIR 8259 series, SP.800-53r5 (Security and Privacy Controls for Information Systems 
and Organizations) and SP.800-213 (loT Device Security Guidance for the Federal Government). 

5. Health Delivery Organization (HDO) 


Introduction | 21 


evaluate the level of risk a MiOT device poses to IT systems and to determine whether or not to permit its use in 
healthcare/IT environments. 


The current state of lol/MiOT cybersecurity and privacy protection using historical and current industry 
guidance & best-practices; recommendations by federal agencies; NIST publications; and federal laws are 
reviewed for similarities and differences which are then incorporated into a Security Assessment. 


Variations in data transmission and storage between IOT/MiOT devices and “traditional” (or classic) Information 
Technology (IT) hardware are presented along with challenges lolT/MiOT pose to cybersecurity and privacy 
protection. 


Finally, a process for evaluating cybersecurity and privacy protection via Security Assessment is offered along 
with enhancements for validating results. Doing so demonstrates general compliance with both NIST guidance 
and HIPAA/HITECH requirements. 
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Governance & Oversight 


MIoT GOVERNANCE & OVERSIGHT 

By definition, MloT devices are lol devices used for a specialized purpose (healthcare). Specialization 
notwithstanding, MIoT devices are subject to the same cybersecurity and privacy protection requirements as 
non-MloT or lol devices. According to the Food and Drug Administration (FDA), cybersecurity is a shared 
responsibility between the FDA and “device manufacturers, hospitals, healthcare providers, patients, security 
researchers, and other government agencies including the U.S. Department of Homeland Security's 
Cybersecurity & Infrastructure Security Agency (CISA) and U.S. Department of Commerce.” 


U.S. FOOD AND DRUG ADMINISTRATION (FDA) 

The Department of Health and Human Services (HHS), Food and Drug Administration (FDA) is responsible 
for medical device oversight. According to the General Accounting Office (GAO), the FDA is responsible “for 
ensuring the safety and effectiveness of medical devices in the United States”? 


In 2012, the GAO recommended in its August Highlights report to Congress that the FDA should “develop and 
implement a plan expanding its focus on information security risks.” 


Pursuant to its responsibility the FDA has published guidance for both Premarket (2014) and Postmarket (2016) 
management of cybersecurity in MiOT devices. 


In 2014, FDA Center for Devices and Radiological Health, released Content of Pre-Market Submissions for the 
Management of Cybersecurity in Medical Devices (FDA 1825). This publication provides guidance for Industry, 
and FDA staff. Though ‘Internet of Things’ is not specifically mentioned in the document—-understandable given 
that MiOT devices were in the very early stages of being applied to the Healthcare sector—it nevertheless 
recommends that “medical device manufacturers address cybersecurity during the design and development 
of the medical device, as this can result in more robust and efficient mitigation of patient risks”. Cybersecurity 
areas addressed included identification of threats and vulnerabilities; assessment of the impact of threats 
on device functionality and end users\patients; assessment of the likelihood of threat\vulnerability occurring; 
determination of risk levels; and assessment of residual risk and risk acceptance criteria. Moreover, the 
recommendations specifically cite NIST Cybersecurity Framework categories Identify, Protect, Detect, Respond 
and Recover. 


In 2016, FDA Center for Devices and Radiological Health, released Postmarket Management of Cybersecurity in 
Medical Devices. Similar to FDA 1825, this publication clarifies postmarket recommendations for manufacturers 
to follow relative to identifying, monitoring and addressing cybersecurity vulnerabilities and exploits as “part of 
their postmarket management of medical devices". 


NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST) GUIDANCE 
In 2019, the NIST released Internal Report” (IR) NISTIR 8228, Considerations for Managing Internet of Things (loT) 
Cybersecurity and Privacy Risks. 


1. GAO Highlights, GAO-12-816., 3 

2. GAO Highlights, GAO-12-816., 20 

3. Postmarket Management of Cybersecurity in Medical Devices. Guidance for Industry and Food and Drug Administration 
Staff. 2016. Food and Drug Administration. Department of Health and Human Services. 18 

4. NISTIR (Internal or Interagency Report). Reports of research findings, including background information for FIPs and SPs. 
Source: https://csrc.nist.gov/publications/, Retrieved: 03/22/21. 
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In 2020, NISTIRs 8259(A)(B)(C)(D) were released as supplementary/complementary Guides for loT cybersecurity. 
These publications provided guidance to loT device manufacturers (8259/8259A); guidance for non-technical 
support capabilities (8259B); guidance for Core security baselines (8259C); and guidance for creating a Profile 
for loT Baselines (8259D) for the federal government. 


Pursuant to passage of federal law governing loT cybersecurity’, in December, 2020 NIST published SP.800-213, 
loT Device Cybersecurity Guidance for the Federal Government. This publication, updated in November, 2021, 
outlines loT device cybersecurity requirements and references several NIST Guides which have cross-application 
to HIPAA and HITECH requirements. Among them: NIST Cybersecurity Framework, SP.800-53r5 (Security & 
Privacy Control Catalog), NISTR-8228 and the NISTIR 8259 series. Collectively, these Guides provide the basis for 
a framework which can be used to determine loT/MIoT compliance with cybersecurity and privacy protection. 


SP.800-213 questions, labeled as “Cybersecurity Considerations”, may include several sub-requirements which 
may, in turn, include additional sub-requirements. Although SP.800-213 cybersecurity considerations are not 
completely utilized here they will be incorporated in a later version of this book. 


In addition to FDA and NIST guidance the private sector has added its perspective to MiOT cybersecurity and 
privacy protection. In 2018, the Medical Device Innovation Consortium® (MDIC), a non-profit, public-private 
partnership published Medical Device Cybersecurity Report: Advancing Coordinated Vulnerability Disclosure 
with the purpose of “coordinated vulnerability disclosure (CVD) policies by medical device manufacturers”. 


FEDERAL LAWS AFFECTING MiOT 
New laws were enacted in 2020 and 2021 that will have an important impact on MiOT cybersecurity and privacy 
protection. 


On December 4, 2020, the loT Cybersecurity Improvement Act of 2020’ was signed into law by President Donald 
Trump. This law required, in part, that NIST develop standards and guidelines for the federal government to 
follow governing loT devices used or controlled by a government agency. As stated earlier, NIST guidance can 
be readily adapted by private-sector companies and organizations. 


On January 5, 2021, President Trump signed into law an amendment to the Health Information Technology for 
Economic and Clinical Health Act (HITECH). HR 7898, otherwise known as the HIPAA Safe Harbor provision 
directs HHS to factor, in part, an organization’s use of industry-standard cybersecurity practices during the 
previous twelve (12) months when investigating suspected data breaches or other violations. The amendment 
is meant to encourage healthcare providers and organizations to use NIST best-practices when formulating 
their cybersecurity and privacy protection strategies. 


5. Internet of Things Cybersecurity Act of 2020. Signed into law on December 04, 2020. 
6. https://mdic.org/ 
7. H.R. 1668, Public Law 116-207. The loT Cybersecurity Act of 2020 was first introduced into Congress in 2017. 
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Challenges to Assessing loT\MiOT 


Healthcare is governed by the provisions of HIPAA and HITECH. Both contain specific regulations and\or 
requirements for the protection of ePHI and other sensitive information. Any process, system or device used to 
create, transmit or store ePHI is subject to these provisions. 


For healthcare organizations and providers MIoT devices represent several cybersecurity and privacy protection 
challenges. Central to which is that MIoT devices do not behave, operate, or perform in the same manner 
as traditional IT devices. This difference is due to a MIoT device’s core functions Sensing (retrieving and 
transmitting information about the real world and transmitting it) and Actuating (making changes to the 
physical world). Some of the differences between MIoT and traditional IT include: 


The ability to configure, update and monitor 
Lack of transparency (black box problem) 
Compatibility with existing Infrastructure 
Information security (CIA) 


Mm AWN = 


Third-party access 


The ability to configure, update and monitor means, at a minimum, having access to the MIoT device in order 
to perform routine and as-needed management functions such as access control (e.g., passwords), software 
updates (i.e., patch management) and log review. Due to manufacture design and production this level of 
access may not be available or even possible. It may not even be possible to know, to a reasonable degree of 
certainty, if the MIoT device is functioning properly or at all. 


Lack of transparency (black box problem) is an issue with some MIoT devices due to their design and 
manufacture. Such devices do not allow insight into their configuration, operational settings or performance/ 
activity logs. Lack of transparency prevents normal or routine cybersecurity and privacy protection oversight, 
and introduces risk into an IT environment since the state of compliance (with HIPAA/HITECH regulations) is 
unknowable. 


Compatibility with existing Infrastructure may cause concern for established Datacenters and IT networks. 
Since MIoT devices may operate and function differently than traditional IT devices such difference can result 
in incompatibility with systems that were not designed for MIoT integration. In turn, MloT devices may require 
new management systems for proper operation and oversight with IT Departments finding it necessary to add 
resources (staff & skills or external services) to manage MIoT deployment within their networks. 


Information Security (CIA) is a core tenant of HIPAA. CIA means taking appropriate steps to protect the 
Confidentiality, Integrity and Availability of protected health information (PHI). Ifa MIoT device stores data (not 
all do) it is critical that it be protected—depending on whether or not said information is PHI or CUI-using 
cryptography or some other means of data protection. ‘Black-box’ devices or devices without any type of access 
or insight into their operation or status introduces significant risk in the event of exploit or compromise. 


Third-party access is of concern for MIloT devices which permit no end-user access to their configuration 
settings or operational status (only third-parties). Such “unmanaged” devices may prevent real-time access 


1. or “classic” IT devices such as routers, switches, servers, etc... 
2. Confidential but Unclassified Information (CUI). Reference NIST.SP-800-171 & NIST.SP-800-172. 
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during operational error or failure with access delayed further if the third-party is unavailable. It may also 
prevent those responsible from properly gauging network or operational status of a MIoT device when a 
software or firmware update is required, device End-of-Life (EOL) is reached, or for other routine management 
and maintenance functions. In addition, a manufacturers Software Bill of Materials (SBOM) may be unavailable 
to a healthcare provider that is considering using MiOT devices in its clinical setting(s). 
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Using NISTIR 8228 'Expectations' for 
MiOT Cybersecurity Assessment 


Using NIST guidance (augmented by federal law), FDA guidance and private-sector recommendations a simple 
framework can be created for assessing the level of cybersecurity and privacy protection a MIoT device 
possesses. By using the framework the level of overall compliance (with recommended standards) can be 
obtained which, in turn, can be used to determine acceptable levels of security and risk. 


NISTIR 8228 presents three high-level challenges to loT cybersecurity and privacy protection; Protect Device 
Security, Protect Data Security, and Protect Individuals Privacy. Within each are sub-goals such as Asset 
Management and Vulnerability Management. Expectations are used to identify specific properties or 
capabilities an loT device must possess in order to ensure proper cybersecurity and privacy protection (Figure 
VTable 1). In addition, references to NIST Cybersecurity Framework and NIST.SP 800-53r5 (Security Control 
Catalog) are provided along with organizational Implications. 


Table 1: Potential Challenges with Achieving Goal 1, Protect Device Security 





loT Devices, and 
Risk Considerations 


Challenges for Individual 


Causing the Challenges 


Affected Draft NIST SP 
800-53 Revision 5 
Controls 


Implications for the 
Organization 


Affected Cybersecurity 
Framework Subcategories 





Asset Management 





Expectation 1: The device has a built-in unique identifier. 





that the organization's 
asset management 
system can access or 
understand. 





Risk Consideration 2 


. The loT device may not 
have a unique identifier 





« CM-8, System 
Component Inventory 





May complicate 


device management, 
including remote 
access and 
vulnerability 
management. 





« ID.AM-1: Physical devices 


and systems within the 
organization are inventoried 








Figure 1/Table 1 


By assessing individual compliance with twenty-five 
(25) Expectations overall compliance can be assessed 
and quantified. This information can then be used to 
a) evaluate risk, b) identify MiOT weaknesses or 
vulnerabilities, c) gauge the level of IT management 
required and d) evaluate whether or not to allow the 
MiOT device into a network. 


In addition to NISTIR 8228 Expectations, associated 


NISTIR 8259 series publications identified three (3) cybersecurity requirements not contained in NISTIR 8228. 
Since NISTIR 8259 series is intended for loT manufacturers or federal government agencies these additional 
requirements are included in the assessment framework as optional considerations since it may not be 
possible to obtain sufficient detail to satisfy their security requirement(s). 
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Evaluation Process 


The evaluation process consists of determining compliance (with NISTIR 8228 Expectations) and assessing the 
level of risk (acceptable, correctable or unacceptable) an MiOT device presents to a healthcare organization’s IT 
environment. The process should also include evaluation with HIPAA/HITECH requirements for the protection 
of PHI. Compliance-with-Expectation should be completed by either the MiOT device manufacturer or vendor 
on behalf of the healthcare provider considering its use. An assessment can be completed by the healthcare 
provider but may be inaccurate—through no fault of the healthcare provider—unless supporting or 
corroborating evidence (or documentation) is provided by manufacturer or vendor. 
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Methodology, Design & Variables 


Note: The MiOT Assessment tool is designed in a similar manner as the Security Assessment using NIST.SP 
800-171r2/172. 


Microsoft Excel was used to create the MiOT Security 





Assessment Workbook (Figure 2). The workbook 
utilizes NISTIR 8228 Expectations to establish a 
quantitative framework for assessing MiOT 





Figure 2 


cybersecurity and privacy protection compliance. In 
addition to specific Expectation requirements the workbook provides references to associated NIST 
publications for each requirement. 


The assessment process consists of determining compliance (with the Expectation), providing proof of 
compliance via validation point or tool, listing HIPAA Security Rule control type, and including additional 
comments (optional). 


Variables are Compliance, Validation Point/Tool, Control Type and Comments. 


COMPLIANCE 
Values are: 
Compliance Value Definition 
Yes 1 The MloT device complies with the Expectation 
No O The MloT device does not comply with the Expectation 
PL (Partial-LOW) 0.25 Device compliance for Expectation is Limited (0%-25%) 
PM (Partial- MODERATE) 0.50 Device compliance for Expectation Moderate (25%-50%) 
PH (Partial-HIGH) 0.75 Device compliance for Expectation is High (50%-75%) 
Does Not Apply O Expectation does not apply to the device (requires explanation) 
Alternate Approach ] An alternate approach is used to comply with the Expectation 
Unknown O it is unknown if compliance with Expectation is possible 


Note: compliance which exceeds 75% of Expectation requirement(s) is deemed satisfactory although this value 
can be adjusted depending on an organization's needs, requirements or preference. 


Numerical values (O-1) are automatically added to the value column based on compliance statement. Values 
are summed and used to determine overall level of MloT cybersecurity and privacy protection compliance (with 
NISTIR 8228 Expectations). 


1. HIPAA Security Rule control types are Administrative, Technical or Physical (Privacy protection). 
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PROOF-OF-COMPLIANCE (VALIDATION POINT/TOOL) 
This variable represents a process, procedure or tool (manual or automated) which is used as auditable proof or 
evidence that the Expectation is being satisfied. 


For example, for DEVICE SECURITY/Asset Management Expectation: the device has a built-in unique identifier 
the validation point may be the short statement “device ID/SN can be read by IT Asset Management System” 
with a tool reference to ABC Asset Management program or application. Validation is to provide sufficient 
supplementary or complementary information proving that the Expectation is being met. 


SECURITY CONTROL/TYPE 

This variable directly references HIPAA’s Security Rule which requires that security controls be categorized as 
Administrative, Technical or Physical. Most often, a security control has but a single categorization however 
there are instances where a control may apply to multiple categories. For example, establishing an operational 
incident-handling capability may be categorized as both an Administrative and Technical control. 


COMMENTS 
This variable provides for additional information. 


2. Short, concise statements are preferred for clarity and readability. 
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Using the Assessment Workbook 


Once the MiOT assessment questionnaire is complete its information is then used to compute individual 
requirement and overall compliance with NISTIR 8228 Expectations in both numerical and graphic (radar or 
spider chart) formats (Figure 3). This view allows evaluators to identify areas of weakness or vulnerability and to 
determine the level of cybersecurity and privacy protection when considering the use of a MIOT device in their 
network environment. 





While only compliance results for NISTIR 8228 are 
shown in Figure 3 results for NISTIR 8228 & 8259A 
(Cybersecurity recommendations for loT 
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manufacturers) are also provided in the workbook. 




















Distinction is made due to NISTIR 8259 series focus on 
























































device manufacturers instead of end-users of MiOT 
Figure 3 


technology. 

A data table and radar (aka spider) chart provide tabular and graphical depiction of each Expectation value for 
aggregate compliance. The radar chart is especially useful for a birds-eye view (BEV) of deficiencies and areas 
which need to be addressed. 


An acceptable compliance level is left to the discretion of the evaluator or organization as there is no published 
standard (although 75% or better is normally considered acceptable). Acceptable levels, however, can be 
designated for both individual Expectation and aggregate levels. 


Regardless of threshold, compliance provides an organization with an idea of how well a MiOT device under 
consideration compares to established or recommended industry-standards. It is also used for determining the 
degree of risk (the MiOT represents) and ultimately whether or not its use is acceptable to a healthcare provider 
or organization. 


1. A radar chart compares the values of three or more variables relative to a central point. It’s useful when you cannot directly 
compare the variables and is especially great for visualizing performance analysis or survey data. 
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Advantages and Benefits of using NISTIR 
8228 for MiOT Assessment 


1. NISTIR 8228 Expectations can be used to evaluate MiOT security in alignment with HIPAA\HITECH 
requirements. At present, there are few assessments designed specifically to evaluate MiOT 
cybersecurity risk and/or privacy protection. 

2. Use of NISTIR 8228 Expectations take advantage of specific requirements for the protection of Device, 
Data and Privacy in order to evaluate security and risk’. 

3. The security assessment approach offered through NISTIR 8228 is easy to use, flexible, repeatable, and 
employs current industry Best-Practices and guidance for both MiOT manufacturer and healthcare 
organization. 

4. The use of NISTIR 8228 adheres to the intent of HITECH\HIPAA ‘Safe Harbor’ provision which 
encourages and incentivizes healthcare providers and organizations to use NIST publications and 
Best-Practice guidance when considering Cybersecurity and Privacy Protection programs. 

5. Employing NISTIR 8228 Expectations suggests an assessment process and methodology that is 
adaptable to non-federal sectors, and which can be used for regulatory and/or legal compliance. 


Healthcare providers (i.e., Covered Entities) are mandated by HIPAA and HITECH to protect the Confidentiality, 
Integrity and Availability (CIA) of Electronic Protected Health Information (ePHI). This requirement extends to 
technology providers and Business Associates (BA) who directly support (healthcare) providers and use MiOT 
devices to satisfy this purpose. 


NISTR 8228 can be used to evaluate MIOT device compliance with other cybersecurity best practices relative 
to Device, Data and Privacy protection. Moreover, NISTIR 8228 associates its requirements to other NIST 
publications governing loT and Cybersecurity including NIST Cybersecurity Framework, SP.800-53r5 (Security 
Control Catalog) and NISTIR 8259 series publications. 


Finally, NISTIR-8228 can be used to create a documented history of compliance. Such history can serve as a 
guide for healthcare organizations when considering changes to its technology and/or network environment. 


1. Risk mitigation tiers are REDUCE, AVOID, ACCEPT and TRANSFER. 
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SECTION IV 


APPENDIX 
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Appendix A - Assessing Enhanced 
Security 


NIST published SP.800-172A, Assessing Enhanced 
Draft NIST Special Publication 800-172A Security Requirements for Controlled Unclassified 
Information in April 2021 (Figure 1). 





It is intended for use with SP.800-172, Enhanced 
Assessing Enhanced Security Requirements Security Requirements for Protecting Controlled 


for Controlled Unclassified Information Unclassified Information. 


SP.800-172A provides procedures for evaluating the 


coverage and depth of a security/risk assessment 
RON ROSS 


VICTORIA PILLITTERI which, according to its abstract 
KELLEY DEMPSEY 


u 


can be used to 
facilitate risk-based decisions by organizations 
related to the CUI enhanced security requirements.” 


SP.800-172A uses assessments methods and objects 


This publication is available free of charge from: along with a set of determination statements related 
https://doi.org/10.6028/NIST.SP.800-172A-draft 





to the CUI security requirement. Methods are 
Figure 1. NIST SP.800-172A Cover Examine, Interview and Test with each possessing the 
attributes depth and coverage. 


Assessments produce assurance cases for determining compliance. As defined by NIST “An assurance case 
is a body of evidence organized into an argument demonstrating that some claim about a system is true”. 
Assurance cases aid in the determination of compliance with the security requirement. 


In order to meet the requirements of SP.800-172A a simple matrix has been created in the Security Assessment 
workbook which contains both method and attribute. This matrix is applied to each enhanced requirement as 
seen at the far right of figure 2. Each method assigns an attribute-level (Basic, Focused and Comprehensive) 
for depth and coverage attributes. 


‘SP.800-172A 


Assessment 


=e Aa iiel oy _owe _ A olying enhanced security requirement assessment 


0 Veilly the integity of [secuily-cilical 0 essential soRwara] using rool oftrust mechanisms or clyplographic signalues. Examine comprehensive _ Basic 





= = is not required for completion of the Security 

Figure 2. SP.800-172A Matrix example war : , ‘ 
Assessment nor does it influence satisfaction (i.e., 

compliance) values (Y/N — 0, 1) or calculation. While 
not designed for medium-level security assessments its use offers a qualitative view for enhanced security 
compliance and, as has already been mentioned, can be used to develop assurance cases which aid decision- 


makers in determining risk and compliance. 


The reader is directed to Appendix C of SP.800-172 for complete description and discussion. Note: the 
assessment process, method and procedure has also been applied to the Security Control Catalog 


. NIST SP.800-172A, Ch.2.2 Assurances Cases, p.5. 
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(SP.800-53r5) and can be found in NIST SP.800-53Ar5, Assessing Security and Privacy Controls in Information 


Systems and Organizations, Appendix C. 


Finally, assessment methods, definitions and attributes have been reproduced for reference in the Security 


Assessment workbook. 
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Appendix B - Adversary Effects 


Adversary Effects is a new section (Appendix D) included in NIST SP.800-172 (Enhanced Security Requirements 


for Protecting Controlled Unclassified Information). 


NIST Special Publication 800-172 





Enhanced Security Requirements for 
Protecting Controlled Unclassified 
Information 

A Supplement to NIST Special Publication 800-171 


RON ROSS 

VICTORIA PILLITTERI 
GARY GUISSANIE 
RYAN WAGNER 
RICHARD GRAUBART 
DEB BODEAU 


Adversary Effects is a new section (Appendix D) 
included in NIST SP.800-172 (Enhanced Security 
Requirements for Protecting Controlled Unclassified 
Information). As described: 


Finally, a protection strategy and adversary effects 


section describe the potential effects of 
implementing the enhanced security requirements 
on risk, specifically by reducing the likelihood of 
occurrence of threat events, the ability of threat 
events to cause harm, and the extent of that harm. 


Five high-level, desired effects on the adversary can 


be identified: redirect, preclude, impede, limit, and 


This publication is available free of charge from: 
https://doi.org/10.6028/NIST.SP.800-172 


; 
expose. 





: The effects themselves contain specific classes of 
Figure 1. NIST SP.800-172 Cover frect 
effects: 


Deter, divert, and deceive in support of redirect 

Negate, preempt, and expunge in support of preclude 
Contain, degrade, delay, and exert in support of impede 
Shorten and reduce in support of limit 

Detect, reveal, and scrutinize in support of expose 


NIST describes the specific effects as tactical (i.e., pertaining to a specific threat event or scenario). Detailed 
explanations of each effect can be found in appendix D. 


Using the effect values a matrix has been created as an example of mapping which adverse effects occur if an 
associated enhanced security control is implemented. There is no effort made to quantify the values either per 
control or by individual (adversary) effect as none is provided in the NIST publication. A general view, however, 
of overall impact a particular control has is achieved by viewing the results in each effect’s column. It is clear 
that controls which are not implemented (‘N’ or ‘D’ response) preclude the intended effect whereas ‘Y’ or ‘P’ 
confirm it. 


1. SP.800-172, 8 
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NIST-SP.800-172 Adversary Effects Map 
(Ref. Appendix D.) 


Control Family 


{Ujimit 





F1: Access Control 

















|F2: Awareness and Training 
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There are 34 enhanced-security controls 


Figure 2. SP.800-172. Adversary Effects Map column 


definitions: 


values in this mapping table are manually entered. 


Map column definitions: 


Control Family Name 

# (corresponding Control Family requirement 
number) 

C (compliance value). Compliance is defined as (Y)es, 
(N)o, (P)artial and (D)oes not Apply. Reference 
Security Assessment Snapshot tab for explanation of 
Compliance value 

Adversary Effects: Redirect, Preclude, Impede, Limit 
and Expose 


If a Control Family contains no adversary effects its 
listing is highlighted in light blue. 


Adversary Effects not associated with a particular 
control requirement are blank. 


Positive and negative (or neutral) effects are 
highlighted in light and medium gray respectively. 


Note: unlike other elements of this workbook the 


Adversary Effects have been included in the Security Assessment workbook (to reflect inclusion in SP.800-172) 


but since they are not ordinal it is not possible to quantify their value. As such, a high-level matrix map has been 


created to show which effects have been achieved if an enhanced security-control is implemented (Figure 1) 


with the table providing an overall snapshot of Adversary Effects. 


The reader is directed to Appendix D of SP.800-172 for complete description and discussion. 
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